home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000059_timbl _Thu Mar 5 15:25:08 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  6KB
  1. Return-Path: <timbl>
  2. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA20144; Thu, 5 Mar 92 15:25:08 GMT+0100
  4. Date: Thu, 5 Mar 92 15:25:08 GMT+0100
  5. From: timbl (Tim Berners-Lee)
  6. Message-Id: <9203051425.AA20144@ nxoc01.cern.ch >
  7. Received: by NeXT Mailer (1.62)
  8. To: ses@cmns.think.com, peterd@expresso.cc.mcgill.ca (Peter Deutsch)
  9. Subject: Re: Draft: Universal Document Identifiers
  10. Cc: iafa-request@kona.cc.mcgill.ca, cni-arch@uccvma.bitnet,
  11.         www-talk@nxoc01.cern.ch, wais-talk@think.com, iafa@cc.mcgill.ca,
  12.         rare-wg3@surfnet.nl, nisi@merit.edu
  13.  
  14. [Admin: If anyone is missing documents from this discussion which I  
  15. have, they are all in a mailbox  
  16. file://info.cern.ch/pub/www/doc/udi/discussion.mbox. Some of the  
  17. messages were sent to only some of the lists.  Also, I mis-spelled  
  18. the name of cni-arch.uccvma in my original posting, so some replies  
  19. have not gone there. I will not repost them.  The orginal udi paper  
  20. is slightly updated now. Same UDI -- no versioning ;-)]
  21.  
  22. Now, about these USDNs:
  23.  
  24. > Date: Thu, 5 Mar 92 07:32:50 EST
  25. > From: ses@cmns.think.com
  26.  
  27. There have been several messages now with a common theme: That what I  
  28. called in the udi1 paper a "lasting registered name" is better than  
  29. an "address".
  30.  
  31. Peter Deutsch argues the point at length in  
  32. <9203042206.AA12411@expresso.cc.mcgill.ca>, using the term USDN by  
  33. analogy with ISBN.
  34.  
  35. John Curran on <Thu, 27 Feb 92 19:45:42 -0500> argues the same, and  
  36. also suggests quoting both registered name and address (which I  
  37. wasn't so sure about in case they get out of sync).
  38.  
  39. I completely agree with Peter and Simon's point of view, and I have  
  40. modified the paper to put more emphasis on this. What I obvioulsy  
  41. didn't make clear enough is my feeling that:-
  42.  
  43. 1.There may be more than one USDN scheme, just as there are many  
  44. physical addres schemes.
  45.  
  46. 2. There may be more than two stages: it is  an oversimplifiaction to  
  47. talk of only a USDN and an address: For example, an ISO standard may  
  48. dereference (or as Ed says, "swizzle") to a document produced by the  
  49. IETF which may dereference down to a prospero name which may be a  
  50. pointer to an FTP file.
  51.  
  52. 3. We can't use USDNs now because they aren't there. We need a  
  53. transision strategy.
  54.  
  55. Therefore, UDis were supposed to be able to hold _either_ a USDN _or_  
  56. a physical address. They weren't intended to get involved with the  
  57. discussion of which USDN/ISBN/ISSN/ISDN (?!) scheme is better. So, I  
  58. say, by all means define an USDN scheme, then register it as a  
  59. possible UDI. If is good and everybody uses it, everything will end  
  60. up with a USDN, and the context will always be USDN documents, so the  
  61. usdn: prefix (or whatever) will not in practice be used. I'm all for  
  62. the market deciding between protocols.
  63.  
  64. Simon:
  65.  
  66. > I'm strongly in favour of the two stage lookup process; X.500 is  
  67. obvious
  68. > technology, although it is rather heavyweight for personal  
  69. computers. An 
  70.  
  71. > alternative might be some sort of DNS/archie-like service. These  
  72. could return
  73. > Tim's UDIs, which could then deliver the good themselves.
  74.  
  75. I would say "a server takes x500 UDIs and returns physical UDIs which  
  76. deleiver the goods themselves.", meaning the same thing.  (I would  
  77. allow it the option of delivering a set of addresses, not just one.)  
  78. Yes, x500 is heavyweight so one can have a lighter protocol which  
  79. accesses a real x500 engine via a gateway with a large cache.
  80.  
  81. > Of course, invdidual information sources should still use local  
  82. document 
  83.  
  84. > numbers where possible, but should provide a way of mapping from  
  85. local-id
  86. > to universal-id when needed.
  87.  
  88. Yes.
  89.  
  90. > One little question: What should be done about document versions?
  91. > Obviously, different versions of a document should have different
  92. > UDSNs, but should there be a simple way to compare USDNs modulo
  93. > versions? 
  94.  
  95.  
  96. Good point.  What about versions which split?  A great spin-off of  
  97. having versions available is that you can refer to a line number in  
  98. them. A line number in a document which is not frozen is useless.  
  99. [This solves a recurring problem in hypertext systems, when one wants  
  100. to link to part of a document to which one has no write access, and  
  101. which may change].
  102.  
  103. > Here are some suggestions.. Eat hot ASN, Cultural Cringer.
  104. > [...]
  105.  
  106. We must be careful not to reinvent the wheel: if the USDN problem is  
  107. the same as the phone book problem (which it seems to be) then we  
  108. should pick up on x500.
  109.  
  110. An important thing about x.500 is that it was designed to scale (I  
  111. hope!).  By contrast as Ed says:
  112.  
  113. | Date: Wed, 04 Mar 92 23:52:05 -0500
  114. | From: Edward Vielmetti <emv@msen.com>
  115. | [...]
  116. | ISBN is hierarchical so you can stamp out your own
  117. | unique ID's; ISSN (international standard serial number) has
  118. | a central cataloging authority.
  119.  
  120. and i doubt whether either of those will scale to allow document  
  121. publishing on the net by every kindergarten child etc etc twice a  
  122. minute. That's why I assume x500 is best in theory at least. But tell  
  123. me I'm wrong.
  124.  
  125. Ed also mentions message-ids which are after all unique. The trouble  
  126. is, there's no way of looking up where to find them.
  127.  
  128.     Tim
  129.  
  130. __________________________________________________________
  131. Tim Berners-Lee                       timbl@info.cern.ch
  132. World Wide Web initiative             (NeXTMail is ok)    
  133. CERN                                  Tel: +41(22)767 3755
  134. 1211 Geneva 23, Switzerland           Fax: +41(22)767 7155
  135.  
  136.  
  137.  
  138. 
  139.